home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
tsql
/
doc
/
tsql.mail
/
000042_kalua@cs.indiana.edu _Wed Mar 17 22:39:43 1993.msg
< prev
next >
Wrap
Text File
|
1996-01-31
|
6KB
|
120 lines
Message-Id: <199303180339.AA17498@optima.cs.arizona.edu>
Received: from moose.cs.indiana.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
id AA17498; Wed, 17 Mar 1993 20:39:00 MST
Received: by moose.cs.indiana.edu
(5.65c/9.4jsm) id AA04759; Wed, 17 Mar 1993 22:39:43 -0500
Date: Wed, 17 Mar 1993 22:39:43 -0500
From: "Patrick P Kalua" <kalua@cs.indiana.edu>
To: tsql@cs.arizona.edu
Subject: Benchmark correspondence
The TSQL Benchmark Draft
************************
Our comments and suggestions to Christian's proposal for TASK I of the
consensus TSQL Benchmark :
1) Restrictions
------------
Since we are still dealing with some aspects of temporal reasoning, the
restriction "Temporal reasoning is beyond ...." should perhaps be
re-phrased to "General temporal reasoning ...."
We also feel that the following restrictions are perhaps too strong and
we should probably relax them abit.
(a) that each relation be used only once in each query
(b) queries involving aggregation facilities be excluded
For the past few years we have been interacting with a number of
demographic researchers and most of their questions seem to be centered
around "events", "event sequences", "waiting times" etc We have also
looked at a number of clinical databases where the queries involving
these same parameters seem to dominate. Events and event sequences are
facts of life and there are a lot of simple queries that we can form
even on the present schema around these parameters. However all those
queries involving event sequences would be eliminated with
restriction (a).
Temporal aggregation may involve :
- summing attribute values of entity instances over time
- counting entity instances over time
- finding max/min/avg of attribute values over time
- summing time period (spell) length
- counting events
- finding max/min/avg of time periods
- finding moving average of attribute values over time
Some of these operations are very simple and yet very important.
Aggregation exhibits some important temporal semantics and since we are
interested more in the semantics of the queries and not efficiency or
performance, we feel that simple aggregation operations ought to be
allowed. This would give us a semantically rich initial benchmark.
**HOWEVER,** we also realize that because of the limited time between
now and June, we could possibly move the addition of these operations
to the second iteration of the benchmark (after the workshop). In that
case, prioritizing the process of lifting the restrictions is something
we should probably consider and agree upon.
2) The Benchmark Database Schema
-----------------------------
2.1) Criteria
We propose adding another criterion :
" The schema should be natural. That is, it should
correspond to a reasonable, though possibly greatly
simplified, segment of the real world. This both
reduces the need to explain the model and enhances
the ability to recognize verball pitfalls in the path
to the query instances."
2.2) Proposed Schema
The proposed schema seems simple enough and suitable for the purpose.
However, we suggest that we add one or two non-temporal (that is,
time-invariant) attributes to the Emp relation - gender and/or
birthdate. This would :
(a) potentially add a few more queries to the pool, and
(b) perhaps more importantly, give us at least one NON-TEMPORAL
attribute in the schema.
If we agree to add only one them, our preference would be gender.
While both of these can be considered to be non-temporal, birthdate
involves some element of time, albeit user-defined time. Gender would
automatically divide the data set into two subsets each which would be
large enough to provide reasonable outputs. We are also influenced by
our contact with social scientists, among whom gender-related queries
are common.
It would also be a good idea, possibly at a later stage, to add a
traditionally multi-valued attribute such as "skills" where the
following snapshot fd holds :
Name --->> Skills
Our assumption here is, of course, that " a person can have multiple
skills at a time and the set changes with time". In this schema, the
assumption for the other attributes (Dept, Salary) is that they are
single-valued. A person can be in only one dept at a time and will
earn only one salary at a time. But over time, the person may have
worked in several departments and may have earned several salaries.
We call such attributes **"serially multi-valued"** as opposed to
"Sex" which is traditionally single-valued and "Skills" which is
traditinally multi-valued.
We welcome any comments.
Patrick P Kalua Ed L Robertson
kalua@cs.indiana.edu edrbtsn@cs.indiana.edu
Indiana University,
Computer Science Dept,
Bloomington, IN 47405.